1. Field of the Invention
The invention relates to a linking technique of software components and, more particularly, to a method for sharing a static link code by software components in a dynamic link library (DLL) and a main program.
2. Description of Related Art
To realize the effect of “what you see is what you get” in mobile phone development tools, a software tool designer typically designs additional dynamic software components for supporting a development environment. However, an important issue for designing dynamic software components is how to allow an application designer to share the same program codes in both design and execution phases in order to integrate all dynamic software components into the development environment through a standard interface.
Among typical dynamic software component techniques, the Object Linking and Embedding/Component Object Model (OLE/COM) technique designed by Microsoft™ is in widespread use. The OLE/COM technique uses a file format of PE32 to implement each OLE/COM component. The OLE/COM components function as DLLs, and accordingly in memory mapping, all components on references and function calls to one another can use the dynamic COM interface to link to a memory address with the OLE/COM component being called. Therefore, the memory mapping in such a software component design can be handled completely by the internal memory mechanism of an operating system. FIG. 1 is a schematic view of a conventional distribution of a memory in which plural COM components are loaded concurrently by an application MainApp.exe. As shown in FIG. 1, the application MainApp.exe concurrently refers the COM components (COM.DLL#1 to COM.DLL#4, and COM.OCX#5). The COM components in the memory can also refer to one another.
Alternatively, Borland™ also uses the format of a dynamic loading package provided by Borland Package Libraries (BPLs) to obtain the dynamic loading. If a software created by the Delphi or C++ Builder development tools is aimed at saving a memory space by means of runtime objects, BPLs are used to achieve the DLL/COM-like purpose, which, similar to the DLL technique, use a memory mapping to load the peripherally supporting software components in the memory upon needs.
However, the technique of dynamic loading components can be applied to the software component domain but not to an embedded system due to the numerous and complex dynamic loading components. Thus, for an embedded system domain, two choices are provided as follows:
(1) All software components are implemented by a static-link design, but such a technique cannot use the software components to realize the effect of “what you see is what you get” in designing tools, unless having a special compiler technique and segmenting blocks technology for compiling.
(2) Two versions of visual software components are provided, which has the advantage that for the needs of designing tools an interface is provided by one version to thereby realize the effect of “what you see is what you get”, yet also has the disadvantage that the high dependence causes the visual software component designer to put in higher efforts and it is not easy for a client using the visual software components to self-design new components and add them in the software.
To overcome the problem of dynamic loading in the embedded system, a conventional technique compiles an application program into the execution file and the peripheral libraries into the dynamic link libraries (DLLs), which link to a core library core.lib. Accordingly, the dynamic real-time loading requirement is met, and the limit of having the special compiler technique is eliminated. However, such a technique wastes the memory space. FIG. 2 is a schematic view of a conventional distribution of a memory in which two DLLs are loaded concurrently by an application Design_Form.exe. As shown in FIG. 2, the file Design_Form.exe and the DLLs Widget.DLL#1, Widget.DLL#2 link to a core library core.lib respectively, and accordingly three core libraries core.lib are presented repeatedly in the memory, resulting in wasting the memory space. Namely, since one DLL requires linking to a separate core library core.lib, the memory space is relatively wasted when all DLLs are loaded in the memory.
To overcome the aforementioned problem in wasting memory, a solution is to link all libraries via a static library. As shown in FIG. 3, since the core library core.lib of all static links has only one body, the file Design_Form.exe and the libraries Widget.DLL#1, Widget.DLL#2 link to same core file core.lib to thereby save the required memory. However, such a technique does not have the advantage of dynamic loading and reduces the flexibility required by a user for a system design. Therefore, it is desirable to provide an improved method to mitigate and/or obviate the aforementioned problems.